Rakendustevahelise suhtluse valdamine: Frontend'i mikro-frontend'i sündmustesiin

Kaasaegse veebiarenduse valdkonnas on mikro-frontend'id kujunenud võimsaks arhitektuuriliseks mustriks. Need võimaldavad meeskondadel ehitada ja juurutada kasutajaliidese iseseisvaid osi, soodustades paindlikkust, skaleeruvust ja meeskonna autonoomiat. Kriitiline väljakutse tekib aga siis, kui need iseseisvad rakendused peavad omavahel suhtlema. Ilma tugeva mehhanismita võivad mikro-frontend'id muutuda isoleeritud saarteks, takistades ühtset kasutajakogemust, mida kasutajad ootavad. Siin tulebki mängu frontend'i mikro-frontend'i sündmustesiin, mis toimib rakendustevahelise suhtluse kesknärvisüsteemina.

Mikro-frontend'i maastiku mõistmine

Enne sündmustesiini süvenemist taastagem lühidalt mikro-frontend'ide kontekst. Kujutage ette suurt e-kaubanduse platvormi. Ühe monoliitse frontend-rakenduse asemel võiks meil olla:

• Tootekataloogi mikro-frontend: vastutab tootenimekirjade, otsingu ja filtreerimise kuvamise eest.
• Ostukorvi mikro-frontend: haldab ostukorvi lisatud tooteid, koguseid ja kassasse suundumist.
• Kasutajaprofiili mikro-frontend: tegeleb kasutaja autentimise, tellimuste ajaloo ja isikuandmetega.
• Soovitusmootori mikro-frontend: soovitab seotud tooteid kasutaja käitumise põhjal.

Kõiki neid saavad erinevad meeskonnad iseseisvalt arendada, juurutada ja hooldada. See pakub olulisi eeliseid:

• Tehnoloogiline mitmekesisus: meeskonnad saavad valida oma konkreetse mikro-frontend'i jaoks parima tehnoloogiapinu.
• Meeskonna autonoomia: arendusmeeskonnad saavad töötada iseseisvalt ilma ulatusliku koordineerimiseta.
• Kiiremad juurutustsüklid: väiksemad, iseseisvad juurutused vähendavad riski ja suurendavad kiirust.
• Skaleeruvus: üksikuid mikro-frontend'e saab skaleerida vastavalt nõudlusele.

Väljakutse: rakendustevaheline suhtlus

Iseseisva arenduse iluga kaasneb oluline väljakutse: kuidas need eraldiseisvad rakendused omavahel räägivad? Mõelge nendele levinud stsenaariumidele:

• Kui kasutaja lisab toote ostukorvi, võib tootekataloog vajada visuaalset märguannet, et toode on nüüd ostukorvis (nt linnuke).
• Kui kasutaja logib sisse kasutajaprofiili mikro-frontend'i kaudu, võivad teised mikro-frontend'id (nagu soovitusmootor) vajada kasutaja autentimisstaatuse teadmist sisu isikupärastamiseks.
• Kui kasutaja sooritab ostu, võib ostukorv vajada tootekataloogi teavitamist laoseisu uuendamiseks või kasutajaprofiili teavitamist uue tellimuste ajaloo kajastamiseks.

Otsest suhtlust mikro-frontend'ide vahel sageli ei soovitata, kuna see loob tiheda sidususe, tühistades paljud mikro-frontend-arhitektuuri eelised. Vajame nende omavaheliseks suhtlemiseks lõdvalt seotud, paindlikku ja skaleeruvat viisi.

Tutvustame frontend'i mikro-frontend'i sündmustesiini

Sündmustesiin, tuntud ka kui sõnumisiin või pub/sub (publish-subscribe) süsteem, on disainimuster, mis võimaldab lahtisidestatud suhtlust rakenduse erinevate osade vahel. Mikro-frontend'ide kontekstis toimib see keskse jaoturina, kus rakendused saavad sündmusi avaldada ja teised rakendused saavad neid sündmusi tellida.

Põhiidee on lihtne:

• Avaldaja (Publisher): rakendus, mis genereerib sündmuse ja edastab selle siinile.
• Tellija (Subscriber): rakendus, mis kuulab siinil konkreetseid sündmusi ja reageerib nende toimumisel.
• Sündmustesiin (Event Bus): vahendaja, mis hõlbustab avaldatud sündmuste edastamist kõigile huvitatud tellijatele.

See muster on tihedalt seotud ka vaatleja mustriga (Observer pattern), kus üks objekt (subjekt) hoiab nimekirja oma sõltlastest (vaatlejatest) ja teavitab neid automaatselt mis tahes olekumuutustest, tavaliselt kutsudes välja ühe nende meetoditest.

Sündmustesiini põhiprintsiibid mikro-frontend'ide jaoks

1. Lahtisidestamine (Decoupling): avaldajad ja tellijad ei pea teineteise olemasolust teadma. Nad suhtlevad ainult sündmustesiini kaudu.
2. Asünkroonne suhtlus: sündmusi töödeldakse tavaliselt asünkroonselt, mis tähendab, et avaldaja ei pea ootama, kuni tellijad sündmuse töötlemise lõpetavad.
3. Skaleeruvus: kui lisatakse rohkem mikro-frontend'e, saavad nad lihtsalt sündmusi tellida või avaldada, mõjutamata olemasolevaid.
4. Tsentraliseeritud loogika (sündmuste jaoks): kuigi rakenduse loogika jääb hajutatuks, on sündmuste käsitlemise mehhanism siini kaudu tsentraliseeritud.

Oma mikro-frontend'i sündmustesiini disainimine

Mikro-frontend'i sündmustesiini implementeerimiseks on mitu lähenemisviisi, millest igaühel on oma plussid ja miinused. Valik sõltub sageli teie rakenduse konkreetsetest vajadustest, kasutatavatest alustehnoloogiatest ja juurutusstrateegiast.

1. Globaalne sündmuste saatja (JavaScript)

See on levinud ja suhteliselt lihtne lähenemine mikro-frontend'idele, mis on juurutatud samas brauseri kontekstis (nt kasutades moodulite föderatsiooni või iframe'i suhtlust). Üksainus jagatud JavaScripti objekt toimib sündmustesiinina.

Implementeerimise näide (kontseptuaalne JavaScript)

Saame luua lihtsa sündmuste saatja klassi:

            class EventBus {
  constructor() {
    this.listeners = {};
  }

  subscribe(event, callback) {
    if (!this.listeners[event]) {
      this.listeners[event] = [];
    }
    this.listeners[event].push(callback);
    return () => {
      this.unsubscribe(event, callback);
    };
  }

  unsubscribe(event, callback) {
    if (!this.listeners[event]) {
      return;
    }
    this.listeners[event] = this.listeners[event].filter(listener => listener !== callback);
  }

  publish(event, data) {
    if (!this.listeners[event]) {
      return;
    }
    this.listeners[event].forEach(callback => {
      try {
        callback(data);
      } catch (error) {
        console.error(`Error in event handler for ${event}:`, error);
      }
    });
  }
}

// In your main application shell or a shared utility file:
export const sharedEventBus = new EventBus();

            

              
                Copy
              
            
          

Kuidas mikro-frontend'id seda kasutavad

Tootekataloogi mikro-frontend (avaldaja):

            import { sharedEventBus } from './sharedEventBus'; // Assuming sharedEventBus is imported correctly

function handleAddToCartButtonClick(productId) {
  // ... logic to add item to cart ...
  sharedEventBus.publish('itemAddedToCart', { productId: productId, quantity: 1 });
}

            

              
                Copy
              
            
          

Ostukorvi mikro-frontend (tellija):

            import { sharedEventBus } from './sharedEventBus'; // Assuming sharedEventBus is imported correctly

// When the cart component mounts or initializes
const subscription = sharedEventBus.subscribe('itemAddedToCart', (eventData) => {
  console.log('Item added to cart:', eventData);
  // Update cart UI, add item to internal state, etc.
  updateCartUI(eventData.productId, eventData.quantity);
});

// Remember to unsubscribe when the component unmounts to prevent memory leaks
// componentWillUnmount() { subscription(); }

            

              
                Copy
              
            
          

Globaalsete sündmuste saatjate kaalutlused

• Ulatus (Scope): see lähenemine toimib hästi, kui mikro-frontend'id laaditakse samas brauseriaknas ja jagavad globaalset ulatust või ühist moodulisüsteemi (nagu Webpacki Module Federation).
• Mälulekked: mälulekete vältimiseks on ülioluline implementeerida korralikud tellimusest loobumise mehhanismid, kui mikro-frontend'i komponendid eemaldatakse.
• Sündmuste nimetamise konventsioonid: kehtestage sündmustele selged nimetamiskonventsioonid, et vältida konflikte ja tagada hooldatavus. Näiteks kasutage eesliidet nagu [mikro-frontend'i-nimi]:sündmuseNimi.
• Andmestruktuur: määratlege sündmuste jaoks järjepidevad andmestruktuurid.

2. Kohandatud sündmused ja DOM-i kaudu saatmine

Teine brauseripõhine lähenemine kasutab DOM-i suhtluskanalina. Mikro-frontend'id saavad saata kohandatud sündmusi jagatud DOM-elemendile (nt `window` objekt või määratud konteinerelement) ja teised mikro-frontend'id saavad neid sündmusi kuulata.

Implementeerimise näide (kontseptuaalne JavaScript)

Tootekataloogi mikro-frontend (avaldaja):

            
function handleAddToCartButtonClick(productId) {
  const event = new CustomEvent('microfrontend:itemAddedToCart', {
    detail: { productId: productId, quantity: 1 }
  });
  window.dispatchEvent(event);
}

            

              
                Copy
              
            
          

Ostukorvi mikro-frontend (tellija):

            
const handleItemAdded = (event) => {
  console.log('Item added to cart:', event.detail);
  updateCartUI(event.detail.productId, event.detail.quantity);
};

window.addEventListener('microfrontend:itemAddedToCart', handleItemAdded);

// Remember to remove the listener when the component unmounts
// window.removeEventListener('microfrontend:itemAddedToCart', handleItemAdded);

            

              
                Copy
              
            
          

Kohandatud sündmuste kaalutlused

• Brauseri ühilduvus: `CustomEvent` on laialdaselt toetatud, kuid alati on hea seda kontrollida.
• Andmeedastuse piirangud: `CustomEvent`'i `detail` omadus saab edastada suvalisi serialiseeritavaid andmeid.
• Globaalse nimeruumi saastamine: sündmuste saatmine `window` objektil võib põhjustada nimekonflikte, kui seda hoolikalt ei hallata.
• Jõudlus: väga suure hulga sündmuste puhul ei pruugi see olla kõige jõudluslikum lahendus võrreldes spetsiaalse sündmuste saatjaga.

3. Sõnumijärjekorrad või välised vahendajad (keerukamate stsenaariumide jaoks)

Mikro-frontend'ide jaoks, mis võivad töötada erinevates brauseri kontekstides (nt erineva päritoluga iframe'id), või kui vajate robustsemaid funktsioone nagu garanteeritud kohaletoimetamine, sõnumite püsivus või edastamine serveripoolsetele komponentidele, võiksite kaaluda väliste sõnumijärjekorrasüsteemide kasutamist.

Näideteks on:

• WebSocketid: reaalajas kahesuunaliseks suhtluseks.
• Server-Sent Events (SSE): ühesuunaliseks serverist-klienti suhtluseks.
• Spetsiaalsed sõnumivahendajad: nagu RabbitMQ, Apache Kafka või pilvepõhised lahendused (AWS SQS/SNS, Google Cloud Pub/Sub).

Implementeerimise näide (kontseptuaalne - WebSocketid)

Tagarakenduse WebSocket-server toimib keskse vahendajana.

Tootekataloogi mikro-frontend (avaldaja):

            
// Assuming a WebSocket connection is established and managed globally
function handleAddToCartButtonClick(productId) {
  if (websocketConnection.readyState === WebSocket.OPEN) {
    websocketConnection.send(JSON.stringify({
      event: 'itemAddedToCart',
      data: { productId: productId, quantity: 1 }
    }));
  }
}

            

              
                Copy
              
            
          

Ostukorvi mikro-frontend (tellija):

            
// Assuming a WebSocket connection is established and managed globally
websocketConnection.onmessage = (event) => {
  const message = JSON.parse(event.data);
  if (message.event === 'itemAddedToCart') {
    console.log('Item added to cart (from WS):', message.data);
    updateCartUI(message.data.productId, message.data.quantity);
  }
};

            

              
                Copy
              
            
          

Väliste vahendajate kaalutlused

• Infrastruktuuri lisakulu: nõuab eraldi teenuse seadistamist ja haldamist.
• Latentsus: suhtlus käib tavaliselt läbi serveri, mis võib tekitada latentsust.
• Keerukus: keerulisem seadistada ja hallata kui brauserisiseseid lahendusi.
• Skaleeruvus ja töökindlus: pakub sageli suuremat skaleeruvust ja töökindluse garantiisid.
• Päritoluülene suhtlus: hädavajalik erineva päritoluga iframe'ide puhul.

Parimad praktikad mikro-frontend'i sündmustesiini implementeerimiseks

Sõltumata valitud implementatsioonist tagab parimatele tavadele vastamine robustse ja hooldatava süsteemi.

1. Määratlege sündmustele selge leping

Igal sündmusel peaks olema täpselt määratletud struktuur. See hõlmab:

• Sündmuse nimi: unikaalne ja kirjeldav identifikaator.
• Andmekoorma struktuur (Payload): sündmuse kaasas kantavate andmete kuju ja tüübid.

Näide:

Sündmuse nimi: userProfile:authenticated

Andmekoorem:

            {
  "userId": "abc-123",
  "timestamp": "2023-10-27T10:30:00Z"
}

            

              
                Copy
              
            
          

2. Kehtestage nimetamiskonventsioonid

Nimekonfliktide vältimiseks, eriti suuremates mikro-frontend-arhitektuurides, rakendage järjepidevat nimetamisstrateegiat. Eesliited on väga soovitatavad.

• Ulatuspõhised eesliited: [mikro-frontend'i-nimi]:[sündmuseNimi] (nt catalog:productViewed, cart:itemRemoved)
• Domeenipõhised eesliited: [domeen]:[sündmuseNimi] (nt auth:userLoggedIn, orders:orderPlaced)

3. Tagage korrektne tellimusest loobumine

Mälulekked on tavaline lõks. Veenduge alati, et kuulajad eemaldatakse, kui neid registreerinud komponent või mikro-frontend ei ole enam aktiivne. See on eriti oluline ühelehelistes rakendustes (SPA), kus komponente luuakse ja hävitatakse dünaamiliselt.

            // Example using a framework like React
import React, { useEffect } from 'react';
import { sharedEventBus } from './sharedEventBus';

function OrderSummary({ orderId }) {
  useEffect(() => {
    const subscription = sharedEventBus.subscribe('order:statusUpdated', (data) => {
      if (data.orderId === orderId) {
        console.log('Order status updated:', data.status);
        // Update component state based on new status
      }
    });

    // Cleanup function: unsubscribe when the component unmounts
    return () => {
      subscription(); // This calls the unsubscribe function returned by subscribe
    };
  }, [orderId]); // Re-subscribe if orderId changes

  return (
    

      
Order #{orderId}
      {/* ... order details ... */}
    
  );
}

            

              
                Copy
              
            
          

4. Käsitlege vigu sujuvalt

Mis juhtub, kui tellija viskab vea? Sündmustesiini implementatsioon ei tohiks ideaalis peatada teiste tellijate töötlemist. Rakendage `try...catch` plokke tagasikutsete ümber, et tagada vastupidavus.

5. Kaaluge sündmuste granulaarsust

Vältige liiga laiaulatuslike sündmuste loomist, mis edastavad liiga palju andmeid või liiga sageli. Vastupidi, ärge looge sündmusi, mis on liiga spetsiifilised ja põhjustavad sündmustüüpide plahvatusliku kasvu.

• Liiga lai: sündmus nagu dataChanged on kasutu.
• Liiga spetsiifiline: productNameChanged, productPriceChanged, productDescriptionChanged võiks parem koondada üheks product:updated sündmuseks, kus spetsiifilised väljad näitavad, mis muutus, või lasta seda käsitleda andmeid omaval rakendusel.

Püüdke leida tasakaal, mis esindab teie süsteemis tähenduslikke olekumuutusi või tegevusi.

6. Sündmuste versioonimine

Teie mikro-frontend-arhitektuuri arenedes võivad sündmuste struktuurid vajada muutmist. Kaaluge oma sündmuste jaoks versioonimisstrateegiat, eriti kui kasutate väliseid sõnumivahendajaid või kui uuenduste ajal ei ole seisakud lubatud.

7. Globaalne sündmustesiin kui jagatud sõltuvus

Kui kasutate jagatud JavaScripti sündmuste saatjat, veenduge, et see oleks tõeliselt jagatud kõigi teie mikro-frontend'ide vahel. Tehnoloogiad nagu Webpack Module Federation muudavad selle lihtsaks, võimaldades teil mooduleid globaalselt eksponeerida ja tarbida.

            // webpack.config.js (in host application)
module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {
        catalogApp: 'catalogApp@http://localhost:3001/remoteEntry.js',
        cartApp: 'cartApp@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        './src/sharedEventBus': { 
          singleton: true, 
          eager: true // Load immediately
        }
      }
    })
  ]
};

// webpack.config.js (in micro-frontend 'catalogApp')
module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: 'catalogApp',
      filename: 'remoteEntry.js',
      exposes: {
        './CatalogApp': './src/bootstrap',
        './SharedEventBus': './src/sharedEventBus'
      },
      shared: {
        './src/sharedEventBus': {
          singleton: true,
          eager: true
        }
      }
    })
  ]
};

            

              
                Copy
              
            
          

Millal sündmustesiini mitte kasutada

Kuigi võimas, ei ole sündmustesiin imerohi kõigi suhtlusvajaduste jaoks. See sobib kõige paremini sündmuste edastamiseks ja kõrvalmõjude käsitlemiseks. Üldiselt ei ole see ideaalne muster järgmisteks juhtudeks:

• Otsene päring/vastus: kui mikro-frontend A vajab mikro-frontend B-lt konkreetset andmehulka ja peab sellele andmele kohe ootama, võib otsene API-kutse või jagatud olekuhalduslahendus olla sobivam kui sündmuse käivitamine ja vastuse lootmine.
• Keerukas olekuhaldus: keeruka jagatud rakenduse oleku haldamiseks mitme mikro-frontend'i vahel võib sobivam olla spetsiaalne olekuhaldusraamatukogu (potentsiaalselt oma sündmuste või tellimismudeliga).
• Kriitilised sünkroonsed operatsioonid: kui on vaja kohest sünkroonset koordineerimist, võib sündmustesiini asünkroonne olemus olla puuduseks.

Alternatiivsed suhtlusmustrid mikro-frontend'ides

Väärib märkimist, et sündmustesiin on vaid üks tööriist mikro-frontend'i suhtlusvahendite seas. Teised mustrid hõlmavad:

• Jagatud olekuhaldus: raamatukogusid nagu Redux, Vuex või Zustand saab jagada mikro-frontend'ide vahel ühise oleku haldamiseks.
• Props'id ja tagasikutsed (Callbacks): kui üks mikro-frontend on otse teise sisse põimitud või koostatud (nt kasutades Webpack Module Federation), saab kasutada otsest prop'ide edastamist ja tagasikutseid, kuigi see tekitab sidusust.
• Veebikomponendid/kohandatud elemendid: saavad funktsionaalsust kapseldada ja suhtluseks eksponeerida kohandatud sündmusi ja omadusi.
• Marsruutimine ja URL-i parameetrid: oleku jagamine URL-i kaudu võib olla lihtne, olekuta suhtlusviis.

Sageli kasutatakse nende mustrite kombinatsiooni tervikliku mikro-frontend-arhitektuuri ehitamiseks.

Globaalsed näited ja kaalutlused

Globaalsele publikule mikro-frontend'i sündmustesiini ehitamisel arvestage järgmiste punktidega:

• Ajavööndid: veenduge, et kõik sündmustes sisalduvad ajatempliandmed oleksid universaalselt mõistetavas vormingus (nagu ISO 8601 UTC-ga) ja et tarbijad teaksid, kuidas neid tõlgendada.
• Lokaliseerimine/rahvusvahelistamine (i18n): sündmused ise tavaliselt kasutajaliidese teksti ei kanna, kuid kui need käivitavad kasutajaliidese värskendusi, peavad need värskendused olema lokaliseeritud. Sündmuste andmed peaksid ideaalis olema keeleagnostilised.
• Valuuta ja ühikud: kui sündmused hõlmavad rahalisi väärtusi või mõõtühikuid, olge valuuta või ühiku osas selgesõnaline või kujundage andmekoorem nende mahutamiseks.
• Piirkondlikud regulatsioonid (nt GDPR, CCPA): kui sündmused kannavad isikuandmeid, veenduge, et sündmustesiini implementatsioon ja kaasatud mikro-frontend'id vastaksid asjakohastele andmekaitseregulatsioonidele. Tagage, et andmeid avaldatakse ainult tellijatele, kellel on selleks õigustatud vajadus ja kelle jaoks on olemas asjakohased nõusolekumehhanismid.
• Jõudlus ja ribalaius: aeglasema internetiühendusega piirkondade kasutajate jaoks vältige liiga "jutukaid" sündmuste mustreid või suuri andmekoormaid. Optimeerige andmeedastust.

Kokkuvõte

Frontend'i mikro-frontend'i sündmustesiin on asendamatu muster, mis võimaldab sujuvat ja lahtisidestatud suhtlust iseseisvate mikro-frontend-rakenduste vahel. Avalda-telli mudeli omaksvõtmisega saavad arendusmeeskonnad ehitada keerukaid, skaleeruvaid veebirakendusi, säilitades samal ajal paindlikkuse ja meeskonna autonoomia.

Olenemata sellest, kas valite lihtsa globaalse sündmuste saatja, kasutate kohandatud DOM-sündmusi või integreerute robustsete väliste sõnumivahendajatega, võti peitub selgete lepingute määratlemises, järjepidevate konventsioonide kehtestamises ja sündmuste kuulajate elutsükli hoolikas haldamises. Hästi implementeeritud sündmustesiin muudab teie mikro-frontend'id isoleeritud komponentidest ühtseks, dünaamiliseks ja reageerivaks kasutajakogemuseks.

Järgmise mikro-frontend-algatuse arhitektuuri loomisel pidage meeles, et eelistada tuleb suhtlusstrateegiaid, mis soodustavad lõtva sidusust ja skaleeruvust. Mõistlikult kasutatud sündmustesiin on teie edu nurgakivi.